Communications network

ABSTRACT

A registration server in a network implementing an API (application programming interface) authenticates services and provides discovery of network resources, prior to registering services with selected network resources. Multiple instances of services and/or multiple service nodes are registered in a single service agreement.

This application is the U.S. national phase of international applicationPCT/GB01/00121 filed 12 Jan. 2001 which designated the U.S.

BACKGROUND

1. Technical Field

The present invention relates to a communications network, and inparticular to a registration server and to other components implementinga programmable interface to resources in such a network.

2. Description of Related Art

Conventionally, advanced communications services in a telecommunicationsnetwork have been implemented using an IN (intelligent network)architecture. In such an architecture, the control logic and variousnetwork resources required to implement advanced services are tightlyintegrated with the communications network, and in general are intendedto be run under the control of the network operator. Such an approachallows robust large-scale applications to be implemented. However, thearchitecture tends to be relatively inflexible, so that developing anddeploying new services can be time-consuming. In addition, it can bedifficult to make network resources available to service providers otherthan the network operator, while maintaining the security and integrityof the network.

Recently, there has been interest in developing communicationsapplications using computing platforms located at the edge of thenetwork and typically operated under the direct control of the serviceprovider. However, since such CTI (computer telephony integration)applications have only indirect and limited access to the capabilitiesof the network, this approach often results in inefficient use ofnetwork resources.

It has been proposed to implement communications networks that includean application programming interface (API) between service componentsembedded in the network, and applications running at the edge of thenetwork. Such an approach combines the benefits of the economies ofscale and of reliability offered by conventional network intelligencearchitectures, with the flexibility and accessibility of the edge ofnetwork approach.

A network including an API as described above has been developed by thepresent applicant in conjunction with other members of the ParlayOrganisation. The Parlay Organisation has published a specification forthe API together with resources to aid implementation. An overview ofthe Parlay API is contained in the document “Parlay API BusinessBenefits White Paper”, Parlay Organisation, Jun. 11, 1999, Published atwww.parlay.org. Versions 1.2 and 2 of the Parlay API specification arealso available from the same site.

In implementing a communications network with a service API, aregistration server is used to control access by edge-of-network serviceapplications to components in the network that provide serviceresources. The registration server may be used to carry out anauthentication process in which the identity of a service application,and the authority of the owner of that application to access networkresources, is checked, for example, using a digital signature, and adatabase listing authorised users of the network. The registrationserver may also be used for the process of discovery, in which, inresponse to a request from a service application, the registrationserver provides details of available network resources. Subsequently,the registration server registers a service application with one or moreservices resources. This may be done by communicating to the serviceapplication the logical identity and physical address of a servicemanager object on a particular service node and/or communicating to theservice manager object data identifying the corresponding serviceapplication.

BRIEF SUMMARY OF EXEMPLARY EMBODIMENTS

A method of operating a communications network including one or moreservice nodes, a registration server arranged to control access byservice applications to the one or more service nodes, and a platformremote from the registration server running one or more communicationsservice applications, the method including:

-   -   a) distributing data identifying service resources available on        the or each service node connected to the communications        network;    -   b) communicating to the registration server a request for access        by at least one of the service applications running on the said        platform to at least some of the service resources identified in        step (a);    -   c) at the registration server, in response to the request of        step (b), executing a service agreement permitting access by the        service application to the one or more service nodes providing        the said requested services resources;    -   d) subsequently binding the service application to the one or        more service nodes;        characterised in that in step (c) the service agreement        specifies plural instances of the service application and/or        specifies a plurality of service nodes and in that step (d)        includes at least one of    -   (i) binding a plurality of instances of the service application        to the one or more service nodes; and/or    -   (ii) binding at least one instance of the service application to        a plurality of service nodes.

In the description and claims of the present application, the term“service node” is used broadly to denote a node of the network whichprovides resources for running communications services. It includes, butis by no means limited to, computing platforms located at the edge ofthe network and used for specialised services such as messaging.

Step (d) may include binding a plurality of instances of the serviceapplication to the at least one service node, and the method may furtherinclude distributing successive initial event notifications between theplurality of instances of the service application. The method mayalternatively include registering a plurality of service nodes with atleast one instance of the service application, and distributingsuccessive initial session requests between the plurality of servicenodes.

In the example described below, the service node is a service controlpoint in a network using an IN (intelligent network) architecture.

The present invention provides a method of implementing an API in acommunications network that is better able to support applicationsrequiring a high degree of resilience. This is achieved by amending theimplementation of the API so that the process of registration is nolonger limited to creating one-to-one bindings between serviceapplications and service nodes, but instead allows several instances ofa service application to be registered with a node and or severaldifferent nodes to be registered with one service application.

BRIEF DESCRIPTION OF THE DRAWINGS

Systems embodying the present invention will now be described in furtherdetail with reference to the accompanying drawings in which:

FIG. 1 is a diagram showing a diagram showing a network embodying theinvention;

FIG. 2 is a diagram showing in further detail a service platform for usein the network of FIG. 1;

FIG. 3 is a schematic illustrating the use of an API in the network ofFIG. 1;

FIG. 4 is a diagram showing interfaces between different components of anetwork embodying the invention;

FIG. 5 is a message sequence chart for start-up and registration ofgateways;

FIG. 6 is a message sequence chart for service start-up;

FIG. 7 is a message sequence chart showing gateway failure andrestoration; and

FIG. 8 is a diagram showing client application failure and restoration.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

A communications network comprises an access network 1 and a corenetwork 2. Customer terminals 3 a, 3 b are connected to the accessnetwork 1. Service provider platforms 4 a, 4 b are also connected to theaccess network 1. A registration server 5 is connected to the networkand, as is further described below, is used in implementing an API(application programmers interface) to network resources. Those networkresources include a number of service nodes 6 a, 6 b, 6 c, each of whichincludes a respective gateway GW1, GW2, GW3. The service nodes includehardware and software for running for example, number translationapplications, interactive voice recognition and messaging services. Asnoted above, the term “service node” is used here broadly to denote anode used in running a service application, and is not limited to nodesat edge-of-network locations.

FIG. 2 shows in further detail the architecture of one of the serviceresource nodes. In this example, the service node is a platform known asthe network intelligence platform (NIP). It includes a number ofcommunications servers (CS) that terminate network signalling, in thisexample signalling system number 7 (SS7) common channel signalling. Aglobal data server (GDS) monitors signalling rates and collects callstatistics. Transaction servers (TS) implement the basic service controlfunctions required by the service node. An overload control server (OCS)implements overload control protection both for the service node and forcomponents downstream from the service node. For example, the OSC mayinitiate call-gapping when an overload condition is detected. Theoverload control server and transaction servers are connected to acommon high-speed bus. The gateway (GW) supports a number of instancesof service manager objects that allocate the resources of the differentcomponents within the service node to a particular service application.The different servers making up the service node may each be implementedon a respective UNIX workstation. The different servers communicate viahigh speed optical fibre (FDDI) local area networks (LANS) 21, 22.

As is shown schematically in FIG. 3, the communications networkimplements an application programmers interface (API) betweenapplications running at the edge of the network in the so-called“enterprise domain” and the network components used to implement theservices in the network operator domain. In this example, the interfaceis that defined in the Parlay API specification.

FIG. 4 shows in further detail the interfaces between components of thenetwork implementing the Parlay interface. The interface isobject-oriented and is implemented using two categories of interface:firstly, service interfaces and secondly, framework interfaces. Theservice interfaces of applications access to the capabilities of thenetwork. The framework interfaces provide a surround for the serviceinterfaces. The framework interface implements processes ofauthentication, discovery and registration. The framework objects in thenetwork domain communicate with client FW objects in the user domain. Inaddition, there is a direct interface 4.2 between client applicationsand Parlay services. However, these direct interfaces 4.2 are normallyonly accessed after an application has signed-on via the frameworkinterface 4.1.

In this example, objects implementing the framework FW reside on theregistration server 5. The client applications and client FW run on theservice provider platforms 4 a, 4 b. The Parlay services including thegateways are embodied in the service nodes 6 a, 6 b, 6 c.

When one of the client applications is initialised, it first signs-onwith the Parlay API via the registration server. A Parlay authenticationobject is instantiated on the registration server and provides anauthentication interface that enables mutual authentication of theregistration server and the client application. In the process ofauthentication, the application returns an identifying code to theregistration server. The registration server includes a database ofrecognised applications. The registration server performs a look-up onthe application ID and may also retrieve a cryptographic key specific tothe application.

In the discovery phase, applications request from the registrationserver discovery of a service feature identified by a property name andproperty values. The Parlay API specification defines a set of propertynames. Parlay services register with the registration server using theappropriate name. In response to the discovery request, the registrationserver returns a service ID which identifies the requested networkservice. Subsequently, the application selects the service. To do this,the application returns to the server the service ID received inresponse to the discovery enquiry. The registration server then returnsa service token which uniquely identifies an instance of the service.Subsequently, before the application can make use of the service, itdigitally signs an agreement with the registration server. The digitalsignature is stored with data including the application ID and theservice token. This digital agreement may be used, for example, as thebasis for subsequent charging by the network operator for use of itsnetwork service. When the agreement has been signed, the registrationserver returns to the application a reference to the object whichimplements the requested network service manager interface.

Implementation of the Parlay interface described above is described infurther detail in the Parlay API specification 1.2. However, inimplementing the invention, some modifications are required to each ofthe interfaces. As conventionally implemented, each single serviceagreement created using the Parlay interface has linked a single gatewayto a single client application. In the present network embodying theinvention, the interface is modified to link multiple gateways tomultiple client applications under a single service agreement. In thisway it is possible for a Parlay-supported end user service to beresilient against gateway or client application failure. Each servicemanager residing in a gateway is given the capability to forward initialevent notifications, for example notification of an incoming call, toavailable client applications using a distribution algorithm, forexample a round-robin algorithm. Similarly, on the client side, theclient application support layer is able to invoke initial sessionrequests. For example, a request to create a call, to one of a number ofavailable gateways using a distribution algorithm. In addition to thesefeatures, the framework FW now includes a polling mechanism to detectthe current state of the gateways that support a registered service.Detection of a failed gateway may be used to trigger an alarm. Theavailability of each of the gateways serving the client application isreported to the client framework. When a restored gateway is detected,after an outage, the framework requests the instantiation of a newservice manager and posts a reference to the new service manager to theclient FW. The client FW implements a polling mechanism that detects thecurrent state of client applications. Detection of a failed clientapplication may be used to trigger an alarm. The availability of each ofthe client applications is reported to the framework FW. When a restoredclient application is detected after an outage, the client FWcommunicates to the new client application a full list of references tothe service managers.

The modifications to the Parlay API will now be described in relation toeach of the specific interfaces shown in FIG. 4. One of thoseinterfaces, that between the client framework and the client applicationdoes not form part of the Parlay API specification but is defined hereas an aid to the description of the system as a whole.

FW—Service Interface

Parlay Service Registration

-   1. Parlay services are registered with the FW. To enable a parlay    service to be supported across more than one gateway, the    registration of the parlay service is distinct from the registration    of the individual gateways that support that service. As shown in    the message sequence chart of FIG. 5, the service node first    requests registration with the FW, and subsequently invokes    registration of all the gateways supporting the service. A separate    invocation is sent for each gateway    Start-up-   1. As shown in FIG. 6, the FW requests the creation of a parlay    service gateway manager in all gateway that supports the parlay    service. A reference to the new service gateway manager is returned    by the gateway.-   2. Once the bind has been competed, the FW passes global event    notification information to the service gateway managers. For    example, the information might include the number ranges that the    application owns. This information is stored in a database.    Failure and Restoration of a Gateway-   1. As shown in FIG. 7, the FW detects the failure of a gateway and    raises an appropriate alarm.-   2. The FW detects the restoration of a gateway and requests the    instantiation of a new parlay service gateway manager for each    service agreement signed. This reuses behaviour from service    start-up.    Failure of a Client Application-   1. As shown in FIG. 8, having been notified of a Client Application    failure, the FW reports this to each of the gateways.-   2. Each gateway removes the stale reference from that gateway's list    of valid Client Applications.    FW—Client FW Interfaces    Start-up (FIG. 6)-   1. The Client FW performs the authentication handshake with the FW.-   2. The Client FW uses the discovery interface to find the Parlay    service(s) to required to run the End User Service.-   3. The Client FW selects a Parlay service and specifies the    number (n) of gateways that is required for resilience purposes. It    also specifies the maximum number of Client Applications (m) that    will bind to the Parlay service gateways This may be specified as    part of the service level agreement.-   4. When the Client FW signs the service agreement the FW returns    references to a list of service gateway managers to the Client FW.-   5. The Client FW passes global event notification information    through the FW, e.g. the Number ranges that the application “owns”.    This information is stored in a database.    Failure and Restoration of a Gateway (FIG. 7)-   1. Having detected a gateway failure, the FW reports this to the    Client FW.-   2. Having detected the restoration of a gateway and requested the    instantiation of a new service gateway manager, the FW sends a    report to the Client FW, passing the reference of the service    gateway manager as a parameter.    Failure and Restoration of a Client Application (FIG. 8)-   1. Having detected a Client Application failure, the Client FW    reports this to the FW.    Client Application—Service Interfaces    Bind (FIGS. 6 & 7)

After start-up or after restoration of a Client Application, and thepassing of service gateway manager references to the ClientApplications:

-   1. The Client Applications bind to each of the service gateway    managers in turn. Each service gateway manager allows no more than m    Client Applications to bind to it.-   2. Service gateway managers distribute events to the Client    Applications using an appropriate distribution algorithm.    Failure and Restoration of a Gateway (FIG. 7)-   1. The failure of a gateway is notified to the Client Application    by:    -   a) The Client FW reporting the failure or    -   b) The Client Application directly detecting the failure (in the        case of an implementation or protocol-specific) or timing out        existing application sessions (e.g. an application call        session).-   2. API invocations relating to existing service sessions are not    transferred to another gateway.-   3. API invocations for new service sessions are transferred to an    alternative gateway. This is done using an appropriate distribution    algorithm to distribute invocations between the remaining gateways.-   4. On gateway restoration, the Client FW passes on a reference to    the new service manager to the Client Applications, which bind to    the new service manager.    Failure and Restoration of a Client Application (See FIG. 8)-   1. The failure of a Client Application is notified to the gateways    by:    -   a) The FW reporting the failure    -   b) The gateways directly detecting the failure (in the case of        an implementation or protocol specific failure) or timing out        existing service sessions (e.g. call session).-   2. API invocations for existing application sessions are not    transferred to another Client Application.-   3. API invocations for new application sessions (initial event    notification) are transferred to an alternative Client Application.    This is done using an appropriate distribution algorithm to    distribute invocations between the remaining Client Applications-   4. The restored Client Application binds with each of the service    gateway managers.    Client FW—Client Application Interface    Start-up (FIG. 6)-   1. The Client FW passes the list of service gateway manager    references to all its Client Applications.    Failure and Restoration of a Gateway (FIG. 7)-   1. Having received a report from the FW on the failure of a gateway,    the Client FW forwards this information to the Client Applications.-   2. Each Client Application removes the stale reference from its list    of valid gateways.-   3. On restoration of the gateway, the Client FW passes the reference    to the new service gateway manager to all its Client Applications    for them to bind to.    Failure and Restoration of Client Application (FIG. 8)-   1. The Client FW detects the failure, raises an appropriate alarm    and reports the failure to the FW.-   2. The Client FW detects the restoration of the Client Application.-   3. The Client FW passes the list of service gateway manager    references to the restored Client Application to bind to.

1. A method of operating a communications network including one or moreservice nodes providing resources for running communications servicesover the communications network, a registration server arranged tocontrol access by client applications to the one or more service nodes,and a platform remote from the registration server running one or morecommunications client applications, the method including: (a)distributing data identifying service resources available on the or eachservice node connected to the communications network, the or eachservice node providing resources for running communications servicesover the communications network; (b) communicating to the registrationserver a request for access by at least one of the client applicationsrunning on the said platform to at least some of the service resourcesidentified in step (a); (c) at the registration server, in response tothe request of step (b), executing a digitally-signed access agreementpermitting access by the client application to the one or more servicenodes providing the said requested services resources, thedigitally-signed access agreement being stored at the registrationserver with associated data including the identity of said clientapplication and of the one or more said service nodes wherein; thedigitally-signed access agreement is a single agreement specifying aspecific fixed number of instances of the client application and aspecific fixed number of services nodes; and the specific fixed numberof instances of the client application is greater than one and/or thespecific fixed number of service nodes is greater than one; and (d)thereafter, in response to execution of the digitally-signed accessagreement in step (c), binding the specific fixed number of instances ofthe client application to the specific fixed number of service nodes. 2.A method according to claim 1, wherein when at step (d) a specific fixednumber greater than one of instances of the client application is boundto the specific fixed number of service nodes, the method furtherincludes distributing successive initial event notifications between thespecific fixed number greater than one of instances of the clientapplication.
 3. A method according to claim 1, including registering aspecific fixed number greater than one of service nodes with thespecific fixed number of instances of the client application, the methodincluding distributing successive initial session requests between thespecific fixed number greater than one of services nodes.
 4. A methodaccording to claim 1, further comprising a step, carried out by theregistration server, of repeatedly polling a specific fixed numbergreater than one of service nodes registered with the registrationserver, and communicating to the or each client application running onthe platform instance data indicating any change in the availability ofthe service nodes.
 5. A method according to claim 1, wherein when aspecific fixed number greater than one of client application instancesare registered with the registration server, the method furthercomprises repeatedly polling each of the specific fixed number greaterthan one of client application instances registered with theregistration server, and communicating to the or each service node dataindicating any change in the availability of the client applicationinstances.
 6. A communications network comprising one or more servicenodes, a registration server arranged to control access by clientapplications to the one or more service nodes providing resources forrunning communications services over the communications network, and aplatform remote from the registration server running one or morecommunications client applications, the network being further arrangedto operate a method comprising: (a) distributing data identifyingservice resources available on the or each service node connected to thecommunications network, the or each service node providing resources forrunning communications services over the communications network; (b)communicating to the registration server a request for access by atleast one of the client applications running on the said platform to atleast some of the service resources identified in step (a); (c) at theregistration server, in response to the request of step (b), executing adigitally-signed access agreement permitting access by the clientapplication to the one or more service nodes providing the saidrequested services resources, the digitally-signed access agreementbeing stored at the registration server with associated data includingthe identity of said client application and of the one or more saidservice nodes wherein; the digitally-signed access agreement is a singleagreement specifying a specific fixed number of instances of the clientapplication and a specific fixed number of services nodes; and thespecific fixed number of instances of the client application is greaterthan one and/or the, specific fixed number of service nodes is greaterthan one; and (d) thereafter, in response to execution of thedigitally-signed access agreement in step (c), binding the specificfixed number of instances of the client application to the specificfixed number of service nodes.
 7. A registration server for implementingan interface to a communication network, the registration servercomprising: a receiver for receiving an access request for serviceresources from a client application being executed; and a processor forexecuting a digitally-signed access agreement permitting access by theclient application to a specific fixed number of-service nodes providingthe service resources in response to the received access request, thedigitally-signed access agreement being stored at the registrationserver with associated data including the identity of said clientapplication and of the specific fixed number of service nodes andspecifying a specific fixed number greater than one of instances of theclient application and subsequently binding the specific fixed numbergreater than one of instances of the client application to the specificfixed number of service nodes by executing the digitally-signed accessagreement in accordance with the identity data associated with thedigitally-signed access agreement, wherein the digitally-signed accessagreement is a single agreement specifying in its associated identitydata a specific fixed number greater than one of instances of the clientapplication and a specific fixed number greater than one of servicenodes and the or each of the service nodes provides resources forrunning communications services over the communications network.
 8. Aregistration server for implementing an interface to a communicationsnetwork, the registration server comprising: a receiver for receiving anaccess request for service resources from a client application beingexecuted; and a processor for executing digitally-signed accessagreement permitting access by the client application to a specificfixed number of service nodes providing the service resources inresponse to the received access request, the digitally-signed accessagreement being stored at the registration server with associated dataincluding the identity of said client application and of the specificfixed number of service nodes and specifying a specific fixed numbergreater than one of service nodes and subsequently binding one instanceof the client application to a specific fixed number greater than one ofservice nodes by executing the digitally-signed access agreement inaccordance with the identity data associated with the digitally-signedaccess agreement, wherein the digitally-signed access agreement is asingle agreement specifying in its associated identity data a specificfixed number greater than one of instances of the client application anda specific fixed number greater than one of service nodes and the oreach of the service nodes provides resources for running communicationsservices over the communications network.
 9. A registration server forimplementing an interface to a communications network, the registrationserver comprising: a receiver for receiving an access request for clientresources from a client application being executed; and a processor forexecuting a digitally-signed access agreement permitting access by theclient application to specific fixed number of service nodes providingthe service resources in response to the received access request, thedigitally-signed access agreement being stored at the registrationserver with associated data including the identity of said clientapplication and of the at specific fixed number of service nodes andspecifying a specific fixed number greater than one of service nodes anda specific fixed number greater than one of instances of the clientapplication, and subsequently binding one instance of the clientapplication to a plurality of service nodes and binding a specific fixednumber greater than one of instances of the client application to one ormore of the service nodes by executing the digitally-signed accessagreement in accordance with the identity data associated with thedigitally-signed access agreement , wherein the digitally-signed accessagreement is a single agreement specifying in its associated identitydata a specific fixed number greater than one instances of the clientapplication and a specific fixed number greater than one of servicenodes and the or each of the service nodes provides resources forrunning communications services over the communications network.
 10. Amethod according to claim 1, wherein when step (d) includes binding aspecific fixed number greater than one of instances of the clientapplication to the specific fixed number of service nodes, the methodfurther includes distributing initial event notifications between thespecific fixed number greater than one of instances of the clientapplication.
 11. A method according to claim 1, including registering aspecific fixed number greater than one of service nodes with thespecific fixed number of instances of the client application, the methodincluding distributing initial session requests between the specificfixed number greater than one of service nodes.
 12. A method accordingto claim 1, wherein in the event of failure of a client application, anew event notification is automatically transferred to an alternativeinstance of the client application specified in the digitally signedaccess agreement.
 13. A method according to claim 1, wherein in theevent of failure of a service node, a new event notification isautomatically transferred to an alternative service node in thedigitally signed access agreement.
 14. A method according to claim 1,wherein in the event of failure of a client application and a servicenode, a new event notification is automatically transferred to analternative instance of the client application and an alternativeservice node specified in the digitally signed access agreement.
 15. Aregistration server for implementing an interface to a communicationsnetwork, the registration server comprising: a receiver for receiving anaccess request for service resources from a client application beingexecuted; and a processor for executing a digitally-signed accessagreement permitting access by the client application to a specificfixed number of service nodes providing the service resources inresponse to the received access request, the one digitally-signed accessagreement being stored at the registration server with associated dataincluding the identity of said client application and of the specificfixed number of service nodes and specifying a specific fixed numbergreater than one of service nodes and a specific fixed number greaterthan one of instances of the client application, and subsequentlybinding one of the instances of the client application to a specificfixed number greater than one of service nodes and/or binding a specificfixed number greater than one of instances of the client application toone of the service nodes by executing the digitally-signed accessagreement in accordance with the identity data associated with thedigitally-signed access agreement , wherein the digitally-signed accessagreement is a single agreement specifying in its associated identitydata a specific fixed number greater than one of instances of the clientapplication and a specific fixed number greater than one of servicenodes and the or each of the service nodes provides resources forrunning communications services over the communications network.